


Part 2: programming and tools 


By Oliver Thamm 


Having dealt with the hardware in Part | of the HCI 2 article, we now 


turn our attention to a summary of how to program the HCI 2, along with 
a look at the necessary tools. 
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The HC12 is a typical CISC micro- 
controller, which means that it has a 
relatively large number of instruc- 
tions with relatively complex modes 
of operation. In general, this type of 
microcontroller is easier to program 
in assembly language than are rep- 
resentatives of the RISC camp. The 
latter type (necessarily) induces the 
generation of ‘spaghetti code’, 
which consists of long and corre- 
spondingly incomprehensible code 
sequences. This does not have to be 
a disadvantage, as long as the code 
generation is left to a compiler. How- 
ever, since we want to start with 
assembly language, the HC12 is just 
what we need. 

The assembly-language instruction 
set of the HC12 consists of nearly 
200 different instructions — which 
may sound like a discouragingly 
large number for a beginner. How- 
ever, this is by no means a hopeless 
undertaking, since the instructions 
are arranged in logical groups and 
some instructions are not used all 
that often. If you deal with the prob- 
lem a step at a time, after a while 
you will have no trouble making use 
of this tangle of instructions. 


From HC11 to HC12 


Previous HC11 users have it espe- 
cially easy. Since all the familiar 
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New HCI? Instructions 


MOVB #$0D,$1234 

In order to write a constant to a particular memory location with the HCI I, you always 
had to do the LDAA/STAA dance. This meant that the value in the accumulator was always 
lost afterwards! One remedy was to bracket the instructions with PSHA and PULA. Fortu- 
nately, the HCI 2 comes with the long-desired Move instruction, which shortens this proce- 
dure. 


DBNE B,Loop 

Loops are everywhere! With the indicated ‘Decrement and Branch if Not Equal’ instruc- 
tion, it is very easy to implement this important basic structure, which you will find in 
dozens of places in every assembly-language program. 


LDAA 1,X+ 

What is being loaded into the accumulator here? The value that is pointed to by the index 
register X. Old news, you say? Not at all, since X is also incremented (increased by |) in 
the process. This means that you can just about do without the old HCI I INX instruction — 
especially when you want to increment by 2, 3, 4 or more! 


LBRA Label 
With the HCI I, you could always jump using BRA — but always too short. LBRA eliminates 
the 8-bit jump region. Of course, this instruction needs one more byte. 


EXG D,X 
Do you know XGDX? This is the same thing. What’s the advantage? EXG works with any 
combination of registers; you can even mix 8-bit and | 6-bit registers! 


PSHD 
Now you can make PSHB, PSHA faster. PSHD does the whole l6 bits in one go. 


SEX 
This is included to boost the sales of the CPU I2 Reference Manual. Besides that, the ‘Sign 
EXtend’ instruction is also handy in C compilers. 


HC11 instructions are present in the 
HC12 set, no initial adjustments are 
necessary. Existing HC11 programs 
can be re-translated using a suitable 
HC12 assembler without generating 
any error messages. With (mathe- 
matical) algorithms, at least, you can 
save a lot of time by reusing existing 
program sources. However, the 
rehosting of routines that address 
specific control registers of the 

i whilefi) i 
microcontroller has a lower chance of p = PORTS | oxo4: 
success. Obviously, a HC11 program PORTS = p; 
that addresses the serial port (SCI) Sas b MERU 
will no longer work properly on the 
HC12 if the address and meaning of 
the SCI control register have 
changed. 
The HC12, however, should not be 
considered to be just a faster, com- 


Ta NolCE12 [Breakpoint] toggle.c Mil E 
File Edit View Memo Symbols Breakpomt Aun Processor Options Window Help 


tA O A wlos] el PS) CLF Pile Dalel | 


"Y 
h 2B X Y PG oF cc MWTELIZC 
OO FF 0899 000 O854D OBFE ES 10111000 





H#include <hciz.h> 


unsigned char p; 


woid wainiyoid) { 


DDRS = 0x04; 





Figure |. NolCE — a typical exam- 
ple of a graphical BDM debugger. 
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Programming Tips and Tricks 


If the program is finally complete, but it still doesn’t work properly, then it’s often hard to 
know what to do. However, there are a few particularly common errors or problems. The 
following are the five most important ones with HCI 2 programming. 


COP 

Many programmers find themselves at a loss if the code works perfectly in the monitor 
program or debugger, but then shows no signs of life when running ‘stand-alone’. The most 
common cause is that the watchdog timer (COP) has been activated after the reset. Even if 
you don’t use this feature, you can’t ignore it. At the very least, you have to disable it imme- 
diately after the reset. 


Program Counter 

Following a reset, the CPU fetches a word from addresses $FFFE and $FFFF. This word 
contains the reset vector, which determines where the CPU starts with the execution of 
machine instructions. If nothing at all works in your program, you should immediately bring 
to mind the helpful existence of the reset vector. 


Stack Pointer 

The stack pointer is used by the CPU each time a subroutine is called. The CPU saves tem- 
porary data in this memory region. If undefined crashes occur (especially after a period of 
successful programming effort), you should have a close and critical look at the stack 
region. You should check the following: (a) is the stack pointer initialised for the correct 
RAM region, (b) are there overlaps with other uses of the RAM and (c) is the size of the 
stack adequate? 


Interrupts 

Interrupts can suspend the operation of a running program asynchronously, or in other 
words, at almost any arbitrary location. Problems only occur if the interrupt routine never 
returns to the main program. If you suspect that this is happening, you should without fail 
immediately check two things: (a) does the interrupt routine conclude with the correct 
instruction (ISR) and (b) are local interrupt flags correctly cleared in the routine? If the local 
interrupt flags are not reset, everything runs in a circle — the interrupt is still pending on 
completion of the ISR, and everything starts all over again from the beginning. 


The monitor versus the interrupt vectors 

If a monitor program is used in the target system, it usually ‘blocks’ the interrupt vectors 
located at the end of the address space. In order to allow these vectors to still be used by 
the application program, it is common practice for the monitor to move the vectors (that it 
does not use itself) into a RAM region. Here the user can enter ‘pseudo interrupt vectors’, 
each of which consists of a three-byte jump instruction of the type JMP Addr. This tech- 
nique should be well known to anyone who is familiar with the HCI I, where it is used in 
the Special Bootstrap mode. 


Calling the AS Assembler 


@echo off 

rem 

rem -L generates xxx.1st 

rem -E generates xxx.log (error list) 
rem 

c:\as\bin\as.exe %l.a -L -E -g noice 
rem 

rem -F Moto specifies S-Record output 
rem +5 deletes S5 records 

rem -r expands the image window 

rem 

c:\as\bin\p2hex %1.p %1.s19 -F Moto +5 -r $0000-Sffff 
if exist %1.p del %1l.p 


patible successor to the HC11. This 
new microcontroller family includes 
a lot of additional improvements, 
such as new instructions and 
addressing modes. Some of the 
major improvements are described in 
the box ‘New HC12 Instructions’. 


Programming tools 


In order to program the HC12, you 
need a set of tools, as with any 
other microprocessor. This starts 
with a PC, with which you can 
write source programs using a (pro- 
gram) editor and then translate 
them into machine language using a 
cross-assembler or cross-compiler. 
After this, the finished program 
(the ‘executable’) must be trans- 
ferred to the target system. Finally, 
your self-crafted program may not 
work properly right off the bat. This 
means that it is advisable to have 
some ideas and aids available for 
doing debugging. 

Everything always starts with the 
source program. To help you devise 
programs, you should acquire a good 
program editor. As to what ‘good’ 
means, you should not judge the 
quality of the software by its price 
alone. What is more important is 
that you can personally work well 
with the software. The author has 
good experience with PFE (Program- 
mer’s File Editor), which is a free- 
ware program from Alan Phillips. 


Translators 


The next step is to hand over the 
source text to an assembler, which 
attempts to find syntactical errors in 
the program. If everything is error- 
free (up to this point), you will 
receive a program in machine lan- 
guage. The S-Record format is the 
established standard here for 
Motorola processors. An S-Record 
file is a text file that represents not 
only all the code bytes of the gener- 
ated machine program, but also 
information regarding the addresses 
where the various parts of the pro- 
gram are to be loaded. 

For the HC12, there are already a 
hefty number of assemblers available 
from various producers. If you have a 
C compiler for the HC12 (for example, 
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Example program for 
serial interface 


: SCIIZ.A 
: Serial-I/O via the Serial Communication Interface (SCI0) 


SCOBD 
SCOCR 


e 
lÁ 


e 
lÁ 


INNES CE 


e 
lÁ 


e 
lÁ 


testSCI 


HUNGER 
Args: 
Retn: 
Dest: 


Func: 
Args: 
Retn: 


Dest: 


eb LIL 


e 
lÁ 


e 
lÁ 


HUNGER 
Args: 
Retn: 
Dest: 


getSCI 
Gude 


e 
lÁ 


e 
lÁ 


Func: 
Args: 
Retn: 
Dest: 


putScI 
empty? 


2/2001 


CPU 68HC12 


include “reghc12.inc” 


equ SCOBDH 
equ SCOCRI 


Initialize SCI (9600 Baud, 


D 


ldd 
std 
ldd 
std 
rts 


#26 
SCOBD 
#$000c 
SCOCR 


8N1, 


Polling Mode) 


; 19200 Bd 


e NTE RE: 
; A:B -> SCOCRI:SCOCRZ 


Test if any character available (received) 


None 
<07 


Il 


ldaa 
anda 


rts 


Get character 


A = char 


loparellig 


ldaa 
rts 


1) -> no char 


SCOSR1 
#$20 


0) -> char available 


; read status 
; receive data reg 


; returns 0, if no data 


from SCI (wait for) 


SCOSR1,$20,getSCI 


SCODRL 


Send a character via SCI 


A = char 


brelr "SCOSR1I7 S80, putsen 


staa 
rts 


SCODRL 
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; receive data reg 


; read out data 


; transmit data reg 


; send data 


the inexpensive ICC12 from Image Craft), you 
need look no further, since an assembler is 
always present in the cross compiler. In this 
case, you can choose from assembly lan- 
guage, C or a combination of the two. 
However, as a beginner you should always 
start with assembly language, since this is 
the only way you can directly recognise how 
the interactions between the hardware and 
software components of the microcontroller 
take place. The insights you gain in this way 
will be very useful when you turn to higher- 
level languages later on. If you are looking for 
a suitable assembler, you will quickly 
encounter the name ‘Alfred Arnold’. This 
author of the universal assembler AS has sup- 
ported the HC12 since 1996. AS has two dis- 
tinctive advantages: it is universal, which 
means that it can be used for all types of 
processors (including the HC11 and a whole 
series of other microcontrollers), and it is 
available free of charge — which is a persua- 
sive argument for private users in particular. 
Writing programs in assembly language is 
certainly not especially easy, and you will 
have to gain experience in actual practice. If 
you do not know anything at all about it, you 
should spend some time with one or two 
introductory books on HC11 programming. 
Everything you learn about HC11 program- 
ming can be directly applied to the HC12. 
Using the assembler is quite simple, at least in 
comparison to the development of the source 
code. The box ‘Calling the AS Assembler’ 
shows a sample sequence in the form of a 
DOS batch file that calls the assembler, 
passes the desired assembler file and finally 
generates the loadable S-Record file (in a sep- 
arate step in the case of AS). The illustrated 
batch file can be called directly from the PFE 
editor using a hotkey, which makes program- 
ming a bit more convenient. 


Transferring code 


You soon will come to the moment of truth, 
when you start the finished program for the 
first time. First, however, the program must 
be loaded into the memory of the target sys- 
tem. There are several ways to do this. 

The first is the classic monitor approach. In 
this case, a monitor program is present on the 
microcontroller board. This piece of firmware 
is located in a small region of the memory of 
the target system, such as in the EEPROM of 
the MCU. When the target system is con- 
nected to the PC via a serial link, you can see 
the start-up message of the monitor program. 
On the PC side, you need a terminal program 
to display the incoming characters on the 
screen and to send your keyboard entries to 
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the target system. 

The terminal program should also have an 
Upload function, so that a file can be trans- 
ferred from the hard disk of the PC to the tar- 
get system. This function is needed to load 
the HC12 program in the form of an S-Record 
file. In practice, this goes as follows: first you 
start the monitor program, and in the termi- 
nal window you see the welcome message. 
Now you can type the load command on the 
keyboard (for example, L<ENTER>). Follow- 
ing this, the program announces that it is 
ready to accept an S-Record file. You then 
start the Upload function in the terminal pro- 
gram and select the desired file, and the PC 
then sends this file to the target system. 
When the end of the file is reached, the mon- 
itor returns the system prompt as notification, 
and the program is now located in the mem- 
ory of the HC12 system. 

The only critical factor with regard to selecting 
a suitable terminal program is that it allows 
the timing requirements of the target system 
to be accommodated. Setting the data trans- 
fer rate (baud rate) should certainly not be a 
problem, but it should also be possible to 
activate a waiting function. If transferring the 
program involves a significant amount of pro- 
gramming time in the target system memory, 
the terminal program must wait for an 
acknowledgement from the monitor after 
sending each line. This ensures that the 
required programming time (for example, 
10 ms per EEPROM location) is not prema- 
turely interrupted by the arrival of the fol- 
lowing S-Record line. The old standby TER- 
MINAL.EXE from Windows 3.1 meets this 
requirement. If you want something more 
modern, you can download Uwe Alterburg’s 
freeware terminal program OC-Console from 
Elektronikladen’s web site: 


(http://www.elektronikladen.de). 


Via the back door 


We have just seen how the program transfer 
works when a monitor program is already 
present in the target system. Clever pro- 
grammers will probably now ask how the 
monitor program itself is loaded into the 
HC12. This question deserves an answer. 
Motorola has come up with a special ‘back 
door’ for the HC12. It is possible to gain 
access to all memory addresses via this back 
door. To a certain degree, it allows you to 
‘look into’ the microcontroller. However, this 
is not all; it is also possible to actively change 
memory locations, halt the CPU, modify 
processor registers and run microcontroller 
programs in single-step mode. 

The operating mode of the HC12 for using 
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this back door is called Background 
Debug Mode, or BDM for short. The 
BDM interface consists of a single bi- 
directional signal line, which is des- 
ignated BKGD. The signal interac- 
tions on the BDM interface are quite 
complex (see Part 1 of this article), 
and above all fast. This is also why a 
BDM pod must always be connected 
between the software development 
PC and the BDM interface of the tar- 
get system. The BDM pod translates 
the data stream, with regard to con- 
tents, signal levels and timing, from 
BDM to RS232 and vice versa. 

There are two forms of debugging 
solutions that work via the BDM. The 
first of these is based on a com- 
mand-line oriented approach. Here a 
terminal program is used to control 
the pod, and thereby the attached 
target system. This is all very similar 
to the previously described monitor 
solution for program downloading, 
with one critical difference: the mon- 
itor firmware runs in the pod instead 
of the target system, so it does not 
utilise any resources of the target 
system! Since the limitations of the 
target system do not have to be 
taken into account with regard to the 
size of the code, it is possible to 
implement very powerful BDM- 
based monitor programs. 

A typical example of this sort of BDM 
tool is B32EVB from Motorola. This is 
a palm-sized circuit board with an 
RS232 connector (9-pin sub-D) and a 
BDM output in the form of a stan- 
dard 6-pin header. Amusingly 
enough, an HC12 is also used on this 
board (an HC912B32), but this is not 
relevant to its function as a BDM 
pod. Lately, there have frequently 
been supply problems with this 
quite inexpensive Motorola tool, but 
the ZWERG32 from Elektronikladen 
can be used as an alternative. 


And through the window 


The second category of BDM tools 
consists of debuggers with graphic 
user interfaces. These mostly come 
as Windows-based software that 
uses a pod with a serial or parallel 
connection for communication with 
the target hardware. With the 
graphic approach, it is naturally pos- 
sible to display a large amount of 
data simultaneously in a much bet- 


ter manner, while at the same time 
hiding the details of the BDM control 
from the user. As a rule, memory 
regions can be displayed in the form 
of hex dumps, while the current sta- 
tus of the processor registers is dis- 
played in a separate region of the 
window. In addition, another win- 
dow shows the contents of the pro- 
gram memory in disassembled form. 
Breakpoints can be entered in this 
window, and program execution can 
also be followed one step at a time 
(see Figure 1). Of course, all this 
convenience comes at a price. Pro- 
fessional-level graphic debugging 
tools (for example, ZAP from Cosmic) 
run to a few thousand pounds. This 
is naturally fully justified if you wish 
to have recourse to the largest pos- 
sible number of powerful program- 
ming features. If your demands are 
somewhat more modest, however, 
you can find attractive debugging 
solutions for the HC12 at signifi- 
cantly lower prices. The author has 
had good experience with StingRay 
(written by Sid Price), among others, 
and with John Hartman’s NoICE 
Debugger. 


Summary 


It is worthwhile to take the plunge 
into HC12 programming for two rea- 
sons. First, the Motorola 16-bit fam- 
ily offers solid performance without 
placing excessively high hurdles in 
front of the programmer with regard 
to the complexity of the microcon- 
troller. Secondly, all imaginable soft- 
ware tools are available, including 
ones that can be obtained as free- 
ware, shareware or ‘low-price’ ware. 
The only other thing you have to fac- 
tor in is the cost of a microcontroller 
board. The ‘serious’ user should also 
include a BDM debugger in his 
toolkit. 

You can find links to the HC12 soft- 
ware mentioned here at the author's 
website (http://hc12web.de), along 
with a vast amount of additional 
information and resources relating to 
the HC12. 
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